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REMARKS 

The present application includes pending claims 1-24, all of which have been 
rejected. The Applicant respectfully submits that the claims define patentable subject 
matter. 

Claims 1, 7, 10-12, 18 and 24 are rejected under 35 U.S.C. § 103(a) as being 
unpatentable over USP 4,896,934 ("Arthurs"), in view of USP 7,151,777 ("Sawey"). 
Claims 2-6, 8-9, 13-17 and 19-23 stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Arthurs in view of Sawey, further in view of USP 6,484,261 
("Wiegel"). The Applicant respectfully traverses these rejections at least based on the 
following remarks. 

I. EXAMINER'S RESPONSE TO ARGUMENTS 

The Examiner states the following at pages 7-10 of the Final Office Action: 
(a) Applicant argues: 

"Initially, the Applicant points out that Arthurs' Output Availability Field in a token 
is not a physical port security bitmap of allowed destination ports. More 
specifically, the Output Availability Field of a list of all output ports (not only 
allowed destination ports), and it indicates which output port has been reserved 
to receive transmitted data." (see page 10, last paragraph). 

Examiner maintains: 

Authurs [sic] discloses "FIG. 6 illustrates an example of a write phase of the 
contention resolution algorithm for the case of a switch having eight input ports 
and eight output ports. The left-hand column of FIG. 6 shows the Source 
Address (SA) Field and Destination Bit Map (d.sub.i .multidot.d.sub.8) of the 
packets present at each of the input ports SA=1 ... SA=8 (i.e. input ports 12-1 ... 
12-N of FIG. 1, where N=8). The right-hand column of FIG. 6 shows the token 
as it sequentially passes each of the eight input ports SA=1 ... SA=8. 

Note that the packet at the input port with SA=1 [i.e., the received frame of 
digital data] is a multicast packet. In particular, its Destination Bit Map Field 
indicates that d.sub.7 =1 and d.sub.3 =1 so that this packet is to be routed to 
output ports 7 and 3 (i.e. output ports 14-7 and 14-3 of FIG. 1). Since, the token 
leaves the token generator 31 with a clear Output Port Availability field and the 
input port with SA=1 is the first input port reached by the token, a. sub. 3 and 
a. sub. 7 are set to logic "1" in the "Output Availability" field of the token [i.e., 
generate the Output Availability Field based on the received frame of digital 
data], and the address "1" for the first input port is written into the subfields A3 
and A7 of the Source Address Field of the token. The token then passes to the 
input port with SA=2 (corresponding to input port 12-2 in FIG. 1). 
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The packet at the input port with SA=2 has d.subA =1 in its Destination Bit Map 
Field. Thus, this packet is a point-to-point (i.e. a unicast) packet to be routed to 
the output port 4 (corresponding to output 14-4 of FIG. 1). Thus, the input port 
with SA=2 modifies the Output Availability field of the token so that a.subA =1 
and so that the source address SA=2 is written into the corresponding Source 
Address subfield A.subA. 

In this manner, the token is modified as it moves from input port to input port 
along the track 31. In the example of FIG. 6, it should be noted that the input 
port SA=7 (corresponding to input port 12-7) is idle, i.e. no destinations are 
indicated in its Destination Bit Map field. In addition, the input ports SA=4,5, and 
6 (i.e. 12-4, 12-5, 126 of FIG. 1) are contending for output ports already 
reserved by other input ports. Thus, these input ports do not modify the token 
and are required to wait for the next transmission cycle to compete again for 
transmission. 

The example of FIG. 6 shows clearly how the optical switch of the present 
invention successfully integrates unicast, broadcast and multicast applications." 
(see figure 6; and column 6, line 42 to column 7, line 19, of Authurs[sic], 
emphasis added) Therefore, Authurs [sic] discloses that the Output Availability 
Field of a token contains the physical port security bit map of only allowed 
ports. 

(b) Applicant argues: 

"In this regard, Arthurs' Output Availability Field is not generated after receiving 
of the frame of digital data." (see page 11, 2nd paragraph). 

Examiner maintains: 

Authurs [sic] discloses "The operation of the switch 10 of FIG. 1 may be 
described as follows. Packets arriving [i.e., receive the frame of digital data] via 
the incoming trunks 16-1 ... 16-N are buffered at the corresponding input ports 
12-1 ... 12-N. These packets are transmitted from the input ports 12-1 ... 12-N 
to the output ports 14-1 ... 14-N in transmission cycles. 

Each transmission cycle comprises two control phases and a transmission 
phase. During the first control phase, a token generated [i.e., generate the 
token field Output Availability Field (physical port security bit map)] by the token 
generator 32 is passed sequentially along the track 31 from one input port 12 to 
the next. The input ports 12 write information into the token indicating the output 
ports 14 to which their packets are to be sent." (see column 4, line 63 to column 
5, line 7, of Authurs[sic], emphasis added). 

Therefore, Authurs [sic] discloses that the Output Availability Field is generated 
after receiving of the frame of digital data, such as disclosed in the claimed 
invention. 

The Applicant respectfully disagrees. In the above citation, the Examiner has 
simply cited, verbatim, from col. 6, line 42 - col. 7, line 19 and col. 4, line 63 - col. 5, line 7 
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of Authurs, without substantively responding to Applicant's detailed arguments stated in 
pages 9-12 of the August 25, 2009 response. 

The Examiner has equated Applicant's "destination port bitmap" to Arthurs' 
destination bitmap field (as illustrated in Fig. 3 of the reference), and Applicant's 
"physical port security bitmap" with Arthurs' Output Availability Field in a token. Initially, 
the Applicant points out that Arthurs' Output Availability Field in a token is not a physical 
port security bitmap of allowed destination ports. More specifically, the Output 
Availability Field of a complete token is a list of all output ports ( not only allowed 
destination ports), and it indicates which output port has been reserved to 
receive transmitted data. See Arthurs at col. 5, line 58 - col. 6, line 3. 

Furthermore, even if we assume, arguendo, that Arthurs' Output Availability Field 
is in fact a physical port security bitmap of allowed destination ports, the Examiner's 
argument is still deficient. More specifically, as clearly stated in Arthurs (e.g., col. 6, 
lines 4-9 and 16-21), the token (including its Output Availability Field) is written 
during the first control phase (the "write phase"), which takes place at the input 
ports and prior to transmitting the data and the token to the reception side (i.e., 
the output ports). This is clearly illustrated in Fig. 1 of Arthurs, where the token 
generator generates the empty token, and then the Output Availability Field of the 
empty token is filled out as it "travels" from input port to input port and then is 
transmitted via the optical star network to the output ports of the receive side. In this 
regard, Arthurs' Output Availability Field is not generated after receiving of the 
frame of digital data. Furthermore, generating of Arthurs' Output Availability Field is 
also not based on information in the received frame of digital data (since it was 
generated prior to the digital data is even transmitted to the output ports). Sawey does 
not overcome the above deficiencies of Arthurs. 

Therefore, the Applicant maintains that the combination of Arthurs and Sawey 
does not disclose or suggest at least the limitation of "comparing said destination port 
bit map with a physical port security bit map to generate a bit map of allowed destination 
ports, wherein said physical port security bit map is generated, after said receiving, 
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based on information in said received frame of digital data," as recited by the Applicant 
in independent claim 1 . 

In general, the Final Office Action makes various statements regarding claims 1- 
24 and the cited reference that are now moot in light of the above. Thus, the Applicant 
will not address such statements at the present time. However, the Applicant expressly 
reserves the right to challenge such statements in the future should the need arise (e.g., 
if such statement should become relevant by appearing in a rejection of any current or 
future claim). 

II. Conclusion 

The Applicant respectfully submits that claims 1-24 of the present application 
should be in condition for allowance at least for the reasons discussed above and 
request that the outstanding rejections be reconsidered and withdrawn. The 
Commissioner is authorized to charge any necessary fees or credit any overpayment to 
the Deposit Account of McAndrews, Held & Malloy, Ltd., Account No. 13-0017. 

Respectfully submitted, 

Date: 25-JAN-2010 By: /Qqnvan I. Beremski/ 

Ognyan I. Beremski 
Reg. No. 51 ,458 
Attorney for Applicant 

McANDREWS, HELD & MALLOY, LTD. 
500 West Madison Street, 34th Floor 
Chicago, Illinois 60661 
Telephone: (312)775-8000 
Facsimile: (312)775-8100 

(OIB) 
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